I want it to be easy for people to create a script that uses the
LogParser library. The easiest thing I can think of is to be able to
just copy and paste the existing example app and then make modifications
to it. This isn’t very easy with the current structure, since the
example app’s code and build config is a bit intertwined with that of
the LogParser library. By putting the example app in a separate
directory, we can make a copy of it by just duplicating the entire
directory.

I intend to add other things at the top level of the Tools directory
(like tools that actually make use of the LogParser library).

While testing a fix for #425, I wanted to have access to the location
history data in a log message.

This adds a switch in a new "Developer settings" section of the Settings
page, which when turned on will emit a JSON serialization of the
location history data when it’s received from the SDK. It’s turned off
by default, because it's only for my specific use case.

…ample app logs

This removes this caveat from ExampleAppSDKLogLine#message:

> The ``SDKLogMessage/message`` of this value is not necessarily the exact
> value that was passed as the `message` argument of
> AblyAssetTrackingCore’s `LogHandler.logMessage(level:message:error:)`.
> It may contain a suffix added by the example apps’ log handlers, to add
> a trailing full stop and information about the `error` argument.

Now, #message contains the exact value passed as the `message` argument
to `LogHandler.logMessage(level:message:error:)`, and #errorDescription
contains the localizedDescription of the error passed as the `error`
argument to that method.

I want access to the exact log message emitted by the SDK, without any
additional characters, so that I can for example emit some JSON in a log
message from the SDK and then parse this JSON in an app that reads the
logs.

I noticed that on a stationary device, or on a simulator set to simulate
a static location, the first trackable added would come online almost
immediately, but subsequent ones would not come online or sometimes
would come online after a long delay.

This is because a trackable will not come online until, after the
trackable is added, we receive a location update from LocationService.
The frequency of location updates from PassiveLocationManager is
determined by that of CLLocationManager, which usually only emits
location updates when the device has moved a sufficient distance (where
“sufficient” is determined by the publisher’s resolution policy).

So, we provide a mechanism for the publisher to request a location
update from CLLocationManager independently of the device’s motion, and
we request a location update when any trackable (except for the first)
is added.

It’s probably worth also explaining how Android behaves in this scenario
and why. My notes here are based on the codebase at commit 3a0d833.

There are two different things that happen in the Android asset tracking
SDK, either of which has the side effect of causing the publisher to
receive a location update when a new trackable is added:

1. The publisher calls DefaultMapbox.changeResolution, which in turn
   ends up removing and re-adding all of (Google SDK)
   FusedLocationProviderClient’s location observers (via its
   requestLocationUpdates method). The documentation for
   FusedLocationProviderClient.requestLocationUpdates implies that
   observers will always receive a location update after this method is
   called (although it might be an old location).

2. (Only in the case where the added trackable is set as the active
   trackable – i.e. when it is added using .track and not .add)

   The publisher calls DefaultMapbox.clearRoute, which calls (Mapbox
   SDK) MapboxNavigation.setNavigationRoutes. Through some process that I
   haven’t looked into, this ends up calling (Mapbox SDK)
   MapboxTripSession.kt’s navigatorObserver’s onStatus, which makes an
   explicit call to updateLocationMatcherResult, which emits a location
   update.

I think that the solution I’ve implemented for iOS turns Android side
effect 1 into an explicit behaviour.

Closes #425.

I need this logging to help me analyse the impact of the change in
a73e823.

This is intended to help me analyse the impact of the change in a73e823.